• crates/cfd-3d/src/fem/solver.rs

crates/cfd-3d/src/fem/solver.rs (2)

460-469: Dead warning block — validate() makes this unreachable.

problem.validate() (line 58) already returns Err if any boundary node lacks a BC, so unconstrained_boundary_nodes will always be empty when execution reaches apply_boundary_conditions_block. The println!("[WARNING] Boundary Leak …") path can never fire. Consider removing it or converting it to a debug_assert!(unconstrained_boundary_nodes.is_empty()) to preserve the invariant check without dead code.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@crates/cfd-3d/src/fem/solver.rs` around lines 460 - 469, The warning about
unconstrained boundary nodes in apply_boundary_conditions_block is dead because
problem.validate() already errors on missing BCs; remove the println! warning
and instead add a debug_assert!(unconstrained_boundary_nodes.is_empty()) (or an
equivalent debug-only check) to preserve the invariant; reference the vector
unconstrained_boundary_nodes and the function apply_boundary_conditions_block
(and the earlier problem.validate() call) so the change is made where the
current warning is emitted.

---

57-58: get_boundary_nodes() is now computed twice per solve() call.

problem.validate()? (line 58) invokes get_boundary_nodes() once. Then apply_boundary_conditions_block() calls it again at line 458. For large meshes this is a redundant O(|cells|) traversal on the hot solve path. Consider caching the result in StokesFlowProblem (e.g., computed lazily on first call) or threading the Vec<usize> from validate through to apply_boundary_conditions_block.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@crates/cfd-3d/src/fem/solver.rs` around lines 57 - 58, The call to
get_boundary_nodes() is being performed twice per solve() because
problem.validate()? invokes it and apply_boundary_conditions_block() calls it
again; fix this by computing boundary node indices only once and reusing them:
either add a cached Option<Vec<usize>> field to StokesFlowProblem and have
get_boundary_nodes() populate and return that (lazy compute on first call,
updating validate to call/get it), or change validate() to return the Vec<usize>
and thread that Vec through solve() into
apply_boundary_conditions_block(boundary_nodes, ...), updating
apply_boundary_conditions_block() signature and callers accordingly so the mesh
traversal is done only once per solve. Ensure get_boundary_nodes(), validate(),
apply_boundary_conditions_block(), and solve() references are updated
consistently.

crates/cfd-3d/src/fem/problem.rs (2)

92-92: Redundant HashMap import — HashSet is the only new need.

HashMap is already imported at file scope (line 8); the inner use only needs HashSet.

♻️ Proposed fix

-        use std::collections::{HashMap, HashSet};
+        use std::collections::HashSet;

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@crates/cfd-3d/src/fem/problem.rs` at line 92, The inner use statement
currently imports both HashMap and HashSet but HashMap is already imported at
file scope; update the inner import (the use std::collections::{HashMap,
HashSet};) to only import HashSet (e.g., use std::collections::HashSet;) so you
no longer redundantly re-import HashMap.

---

242-259: test_boundary_detection_with_markers tests the wrong invariant after the marker pathway was removed.

mesh.mark_boundary(0, "inlet".to_string()) is now a no-op in get_boundary_nodes(). The test only passes because the single-tet topology already makes all faces topological boundaries (each referenced by one cell). It cannot catch a regression where markers are incorrectly reintroduced, nor does it verify the intended new invariant: that a face explicitly marked as boundary but internally shared by two cells is not included. Consider replacing or augmenting this test:

// Demonstrates that boundary markers have no effect on get_boundary_nodes:
// the same result is obtained whether or not mark_boundary is called.
#[test]
fn test_boundary_markers_have_no_effect() {
    let mut marked_mesh = create_test_tet_mesh();
    marked_mesh.mark_boundary(0, "inlet".to_string());

    let unmarked_mesh = create_test_tet_mesh();

    // Both should produce identical boundary node sets.
    let marked_problem = StokesFlowProblem::new(marked_mesh, ..., 4);
    let unmarked_problem = StokesFlowProblem::new(unmarked_mesh, ..., 4);
    assert_eq!(
        marked_problem.get_boundary_nodes(),
        unmarked_problem.get_boundary_nodes()
    );
}

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@crates/cfd-3d/src/fem/problem.rs` around lines 242 - 259, The test
test_boundary_detection_with_markers is asserting the old invariant where
markers affected get_boundary_nodes; since mesh.mark_boundary(...) is now a
no-op for get_boundary_nodes, replace this test with one that verifies markers
have no effect by creating two identical meshes (one with mesh.mark_boundary(0,
"inlet".to_string()) and one without), constructing StokesFlowProblem::new for
each, and asserting that problem.get_boundary_nodes() returns identical vectors
for the marked and unmarked problems; alternatively, add a test that marks a
face that is shared by two cells and assert that get_boundary_nodes() does not
include that face’s nodes to catch regressions if markers are ever reintroduced.

crates/cfd-optim/src/error.rs (1)

35-38: Same commented-out code concern as lib.rs.

MeshExportFailed was already gated by #[cfg(feature = "mesh-export")]. Prefer deleting this block or restoring it behind the proper #[cfg] guard so the compiler validates it, rather than leaving it as a comment that drifts silently.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@crates/cfd-optim/src/error.rs` around lines 35 - 38, Remove the commented-out
legacy MeshExportFailed enum variant or restore it behind the original feature
gate so the compiler checks it; specifically either delete the commented block
for MeshExportFailed or reintroduce it as a variant (MeshExportFailed {
scenario_id: String, message: String }) annotated with #[cfg(feature =
"mesh-export")] and the corresponding #[error(...)] message inside the error
enum so the compiler enforces correctness.

crates/cfd-optim/src/lib.rs (1)

166-202: Consider deleting rather than commenting out the dead code.

Commented-out code silently bitrots — if surrounding types change (e.g., RankedScenario, MeshHandoffRecord, OptimError), the compiler won't flag the divergence. Two cleaner options:

• Delete the block entirely if blue2mesh won't be available on crates.io and this feature is not planned for near-term revival.
• Keep behind #[cfg(feature = "mesh-export")] (i.e., restore the attribute, keep the feature declared but default-off in Cargo.toml, and remove only the path dependency). The compiler then validates the block whenever the feature is enabled in CI.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@crates/cfd-optim/src/lib.rs` around lines 166 - 202, The commented-out
generate_mesh_handoff function (references: generate_mesh_handoff,
RankedScenario, MeshHandoffRecord, OptimError, MeshGenerator, CfdExporter) is
dead code and should be removed or restored behind a real feature flag; either
delete the entire block to avoid bitrot, or re-enable it with #[cfg(feature =
"mesh-export")] and add the feature (default = false) to Cargo.toml so the
compiler validates the function and its types when the feature is enabled (also
remove the path dependency to blue2mesh if you’ll keep the feature but not the
local dep).